Preserve integer inputs when formatting ordinals - #414

Went through this one carefully and it holds up. The bug is real on main, and it isn't just a cosmetic fallback problem — it's an uncaught exception:

>>> ordinal(10**400)
OverflowError: int too large to convert to float
>>> ordinal(-(10**400))
OverflowError: int too large to convert to float

The cause is exactly as the PR implies: float(value) ran before int(value), purely for the finiteness check, and OverflowError isn't in the except (TypeError, ValueError) clause, so it escaped. That contradicts the docstring's own contract — "Works for any integer or anything int() will turn into an integer" — since int() handles these fine.

Reordering to try int() first and only falling back to float() for the non-finite/non-numeric cases is the right shape, because the int path never needed the float conversion in the first place.

I checked the fallback ordering preserves existing behaviour across the awkward inputs rather than just the happy path:

All match main except the two that previously raised. The 10**23 + 1 case is a nice side effect worth calling out: precision is preserved exactly, where a float round-trip would have lost the trailing digit.

pytest tests/test_number.py gives 266 passed here versus 241 on main, so the added coverage is real and nothing regressed.

One note for anyone else verifying this locally: if you have humanize installed in site-packages, pytest will import that instead of the branch and you'll see a pile of unrelated test_metric failures. Forcing PYTHONPATH at the checkout's src/ gives the clean run above — worth knowing before anyone chases those.

Unrelated to the correctness of this change, but since it touches the same function: #405 is fixing the negative-number suffix (ordinal(-1) is -1th on both main and this branch), and the two edits land on different lines, so they should be independent. Neither one covers the other's case.